With increased losses in a recession economy, issuers need faster, better account management tools to control risk. Current account and risk management tools for issuing financial institutions (issuer) do not allow them to receive unsolicited data or other data automatically that could indicate an account or an account holder may have become risky in an online real-time process using data submitted by other issuers. As of yet, there is no simple way for issuers to share fraud data, unauthorized use data and application velocity data at a consumer level in real time.
In an attempt to deliver timely alerts to their member account issuers, some transaction processors offer risk management tools for prevention, detection and resolution of fraud and credit risks including application screening and fraud detection (AFSD) services for new accounts and other tools for detecting fraud and risk on existing accounts. Alerts are used to inform member account issuers of conditions during the application and approval process and conditions that arise after an application is processed, approved, an account is opened and, in the case of credit cards, a card is issued. Alerts delivered after an account is open “retroactively” can provide “new” more recent information that might be relevant to the identifying increased risk during the life of an account. For example, one member account issuer might like to know when one of their consumers has taken various actions such as applying for an account with another member account issuer.
When an account issuer processes an application for an account, it collects information from the consumer applying for the account. In the case of a credit card account application, the issuer typically collects the consumer's name, address, Social Security number, telephone number and other information that can be used for identifying the consumer.
To aid in its decision as to whether to open the account, the issuer will conduct research to determine whether the consumer qualifies under its own internal qualification and risk management policies, systems and protocols. Various issuers will have various requirements for opening an account. For example, a credit card issuer may require the consumer has fewer than X number of other credit card accounts and no convictions of fraud, whereas an online retail site might only require that a consumer have no more than one account with that retailer.
To aid in an account issuer's research to determine whether a particular consumer is account worthy, various consumer-reporting entities provide a multitude of consumer reporting services. For credit card issuers, there are several consumer credit reporting bureaus such Equifax® and Experian® that provide lenders with access to consumer reports that include the status of all tradeline accounts reported into that bureau for that particular consumer under investigation. Consumer credit reporting bureaus can also compute and report an overall credit score for the consumer. The information consumer credit reporting bureaus have combines all individual account level data, such as the age of the account, payment history, the amount of credit and the amount and age of the outstanding balances for a particular consumer. To provide incremental information above what is available through the consumer credit reporting agencies, various transaction processing associations and other organizations have developed numerous services to collect and deliver supplemental risk data to lenders opening accounts including credit card account issuers.
Currently, consumer and other risk data is collected by various data sharing consortiums. Typically, each consortium specializes in solving a particular problem. In the credit card industry, risk products and services are provided by transaction processing associations such as Visa with its Issuers' Clearinghouse Services (ICS). When an account issuer receives the application for a new account from a consumer, the account issuer submits consumer level information along with an application identifier and account issuer entity identifier, such as a bank identification number or BIN. Typical consumer data elements can include, but are not limited to, name, address, phone number, Social Security number (SSN) and birth date.
Every application reported into an ASFD services server receives a response based on the consumer data elements submitted with the application. The response is a confirmation, an alert or invalid. An alert returns information back to the account issuer that submitted the application advising it of any suspicious characteristics or activities as defined by the account issuer. This flexibility is provided to allow issuers to define the types of information they need based on differences in customer prospects, credit card portfolios and risk management protocols. For example, credit card issuers will submit a credit card application with all of the consumers particular consumer data elements, an application identification code and a bank identification number and expect to receive a report regarding the authenticity of the consumer data elements and any reports of fraud or unauthorized use involving those consumer data elements reported by other credit account issuers but they may not want to be advised when a card is lost or stolen or they may want only fraud reported and no application activity.
In addition, all risk service servers collect and store application data for some period of time in order to report historical activity on individual consumer data elements. For example, an ASFD server 140 can keep track of the number of times a particular name or Social Security number is submitted in various credit card applications from multiple issuers. Currently, many ASFD servers can report to issuers whenever it detects a consumer data element level triggering event or consumer data element application velocity threshold.
Consumer data element level triggering events can vary depending on the needs of the account issuer. Some issuers, for example, will want to know the application velocity for a particular Social Security number. That is, the issuer will want to know the rate at which the Social Security number shows up in applications submitted within some defined period of time. As an example, issuer A may wish to be alerted whenever Social Security number XXX-XX-XYZX is observed in 3 credit applications in less than 30 days. The threshold Social Security number velocity therefore is 3 applications per 30 days.
If a triggering event is observed by the ASFD server, current services provide protocols for sending retroactive alerts to the issuers that requested the alerts and defined the triggering event. However, for the ASFD server to send a credit issuer more information than a notification that a triggering event has been observed, the operator of the ASFD server must first verify that a credit issuer has a permissible purpose under the Fair Credit Reporting Act (FCRA).
Permissible purpose is defined in Section 604 of the Fair Credit Reporting Act (FCRA), 25 U.S.C. §1681b. Under FCRA, a credit issuer cannot obtain a consumer report unless they have a permissible purpose to receive a consumer report.
As define under 35 U.S.C. §1681b, permissible purposes for receiving consumer reports are:    (a) In general, subject to subsection (c), any consumer reporting agency may furnish a consumer report under the following circumstances and no other:
(1) In response to the order of a court having jurisdiction to issue such an order, or a subpoena issued in connection with proceedings before a Federal grand jury.
(2) In accordance with the written instructions of the consumer to whom it relates.
(3) To a person which it has reason to believe                (A) intends to use the information in connection with a credit transaction involving the consumer on whom the information is to be furnished and involving the extension of credit to, or review or collection of an account of, the consumer; or        (B) intends to use the information for employment purposes; or        (C) intends to use the information in connection with the underwriting of insurance involving the consumer; or        (D) intends to use the information in connection with a determination of the consumer's eligibility for a license or other benefit granted by a governmental instrumentality required by law to consider an applicant's financial responsibility or status; or Jul. 30, 2004 13        (E) intends to use the information, as a potential investor or servicer, or current insurer, in connection with a valuation of, or an assessment of the credit or prepayment risks associated with, an existing credit obligation; or        (F) otherwise has a legitimate business need for the information                    (i) in connection with a business transaction that is initiated by the consumer; or            (ii) to review an account to determine whether the consumer continues to meet the terms of the account.                        
(4) In response to a request by the head of a State or local child support enforcement agency (or a State or local government official authorized by the head of such an agency), if the person making the request certifies to the consumer reporting agency that                (A) the consumer report is needed for the purpose of establishing an individual's capacity to make child support payments or determining the appropriate level of such payments;        (B) the paternity of the consumer for the child to which the obligation relates has been established or acknowledged by the consumer in accordance with State laws under which the obligation arises (if required by those laws);        (C) the person has provided at least 10 days' prior notice to the consumer whose report is requested, by certified or registered mail to the last known address of the consumer, that the report will be requested; and        (D) the consumer report will be kept confidential, will be used solely for a purpose described in subparagraph (A), and will not be used in connection with any other civil, administrative or criminal proceeding, or for any other purpose.        
(5) To an agency administering a State plan under Section 454 of the Social Security Act (42 U.S.C. §654) for use to set an initial or modified child support award.
ASFD servers and databases do not receive information from issuers as to whether an application was approved and if an account was opened nor do they receive periodic updates from issuers reporting applications into the database about the status of an account, payment history etc. Therefore, it is unknown if a particular issuer meets the requirements of the FCRA and subsequently if they can receive updated information related to the original applicant. To obtain such information, issuers must validate that they have permissible purpose before any retroactive alerts can be delivered to them. This process involves five steps two transactions and delays the receipt of risk information.
When a triggering event is observed by the ASFD server, the ASFD server sends a retroactive alert to one or more credit issuers as the first transaction. The retroactive alert as initially sent to the credit issuers contains no other information other than one of that credit issuers' triggering events has been observed.
FIG. 1A is a flow chart of a current retroactive alert process from the perspective of a credit issuer. Once the retroactive alert with limited information is sent by the ASFD server, the issuer receives the retroactive alert via existing or other communication channels in step 10. In step 15, after determining that it wants to take further action, the issuer verifies to the ASFD server it has permissible purpose under FCRP. This is typically achieved in a second transaction wherein the credit issuer sends an account number with a corresponding application identifier and BIN to the ASFD server to confirm that the credit issuer did in fact open a credit account based on an application it previously submitted to the ASFD server.
Once the issuer verifies it has a permissible purpose for the information that triggered the event, the issuer sends a second transaction, or inquiry transaction, to the ASFD server to request additional information regarding the events that triggered the retroactive alert in step 20. As shown in FIG. 1A, after receiving the alert, the process of getting information regarding the triggering event involves two transactions between steps 10, 15, 20 and finally step 25 in which the issuer receives information about the event that triggered the retroactive alert. Under FCRA regulations, the ASFD server can only send specific information about the account activity for the account issued by the issuer. No information about the activity of accounts not owned by the particular issuer is ever delivered, the ASFD server can only send generalities and nonspecific descriptions of the events.
Finally, in step 30, the issuer can determine whether to investigate the events that triggered the retroactive alert using information received from the ASFD server. A typical issuer response would be to contact the consumer involved to investigate the behavior or the events that triggered the alert or to change the behavioral model or decision tree associated with that particular consumer. In any event, the two-transaction process involved in sending an issuer information regarding the behavior or events that triggered the retroactive alert can be slow and expensive.
Embodiments of the present invention address these and other problems and deficiencies.